Relational Database-as-a-Service (DaaS) platforms support the abstraction of a resource container that guarantees a fixed amount of resources (e.g., two virtual cores, 4 GB of memory, 100 disk IOPS and 1 TB disk space) and a cost per billing interval (e.g., 50 cents per hour). Tenants are responsible to select a container size suitable for workloads. To take advantage of cloud elasticity, DaaS platforms tenants must estimate and manually change the database container size. The tenant is charged for the largest container size used in the billing interval and pays the summation of costs for each billing interval.
Since resource demand cannot be measured, a problem is to estimate demand for database workloads. However, a challenge arises due to the complexity of database engines and how multiple resources interact. For example, if the offered load increases, it does not necessarily mean that that adding more resources will significantly improve query latencies, particularly if queries are mostly waiting for locks on shared data items. Similarly, adding more memory might reduce the need for I/O (input/output) and increase the CPU (central processing unit) demand since more data can be cached. Moreover, when container sizes vary significantly in resources and cost, the penalty for incorrect demand estimation can be high—it results in either poor performance if demand is underestimated or higher monetary cost if demand is overestimated. Still further, most tenants of a DaaS cannot afford to hire sophisticated database administrators with the expertise necessary to make judicious decisions whether and when to scale resources.